In recent years, business intelligence tools have become increasingly utilized by large business enterprises and other organizations. Business intelligence provides current and historical views of business operations by analyzing internal, structured data and business processes of the organization. It is often used to create future models and predictions in order to support better business decision making. As such, business intelligence tools can lead to decreased costs and increased efficiency, productivity and profit margins for many companies.
Business intelligence is usually implemented as software and/or hardware tools that are used to collect and analyze data and to transform the raw data into meaningful and useful information used to enable more effective strategic, tactical, and operational insights and decision-making. As such, a typical business intelligence server relies on data that may reside in a variety of places, including but not limited to databases, repositories, content management systems, application servers, software development frameworks and many other sources.
In a typical business intelligence server, data is collected from all (or some) of these sources and placed into a (virtual or physical) data warehouse or data mart, where it can then be modeled and analyzed before being presented to the user. For example, in the context of collecting data from an application development framework (ADF) source, one approach is to implement a physical layer within the business intelligence server, where data is modeled as a consolidated table that mirrors objects in the ADF layer. An application developer can assemble these compound objects by hand, using a subset of the entities relevant to the domain; the synthesized objects can subsequently be imported into the business intelligence server's metadata and decomposed into dimensions and facts.
However, this composition is usually a manual effort, often requires domain experts, and can be prone to errors in model translation. Another problem arises from having to decide at design-time what the composition should be. Involving all the possible columns of interest can lead to model bloat. Queries against such large objects will accordingly take longer to execute since many unneeded joins are introduced in the execution. On the other hand, limiting what is composed into the consolidated object reduces the flexibility of ad-hoc querying.
An alternative to using compound objects is to retain the original architectural separation and use the constituent objects as defined in the ADF source model. However, this also requires the business intelligence server to model the linkages between these objects. These links can be sufficiently complex that remodeling them in the business intelligence layer is just another variant of the model translation issue.
Additionally, from a performance perspective, since the data sources often do not support aggregation, such queries tend to be slow because aggregations are performed on low level data in business intelligence server. Potentially going through additional servers (e.g. Java Host and ADF) in the network is slower than directly querying the database.